Transparent bridges learn Media Access Control (MAC) addresses on their ports so that frames can be directed efficiently toward their destination, avoiding unnecessary flooding. For instance, if a bridge receives a frame from a particular source MAC address on one of its ports, then that bridge creates an entry in a forwarding database (e.g., in a content addressable memory, or “CAM”) associating that MAC address with that port. Thus, when the bridge receives a frame destined for that MAC address, the bridge need only transmit the frame on that particular learned port. Otherwise, if the bridge does not have an entry for the destination MAC address of the frame, the frame is flooded (transmitted) on all ports (except the receiving port) to ensure that the frame reaches the unlearned destination.
In response to a topology change in a bridged network, a spanning tree protocol (STP) recalculates a new topology, which requires that bridges in the network “flush” (clear/remove) their learned address entries to be repopulated in response to the change. The flush operation is necessary to avoid “black-holing” any traffic by transmitting frames based on obsolete entries (i.e., before, and affected by, the topology change) such that the frames never reach their destination. Currently, then, to provide for immediate restoration of connectivity, (substantially) all filtering database entries are cleared (flushed) and traffic is flooded on (substantially) all ports of the bridges in the network. Because of this, high volume traffic received on uplinks of a bridge may be temporarily forwarded to lower bandwidth access ports, thus saturating their links and impacting their connected end devices. Also, various standards, such as Rapid STP (RSTP), achieve reliability by repeating topology change messages that trigger the flush, so any newly learned (repopulated) address entries from traffic/frames received after an initial flush may be flushed again, adding stress and wasting resources of the affected bridges.